Computers typically execute programs in one or more processes or threads on one or more processors. In developing computer programs, programmers often use “debugging” tools to enable them to verify correct operation of the programs. Using debugging tools, programmers can step through a program and determine whether the results that the program generates at various points are as would be expected. If the results are correct at one point, and not at a subsequent point, the programmer can expect that the portion of a program between the two points is in error. Typically to facilitate debugging, a programmer will insert “breakpoint” instructions at locations in the code he or she wishes a program to stop, to allow him or her to determine whether the program is operating as expected. In debugging code for a single thread in a single process, it is relatively straight-forward to follow operations performed by the processor during debugging.
However, difficulties arise when a program is multi-threaded. Current debuggers for multi-threaded programs are synchronous, that is, they are configured to stop all threads of a program when a breakpoint instruction is encountered in any of the threads. After the threads are stopped, the programmer can issue commands to the debugger to enable it to step through the thread in which the breakpoint instruction was encountered. This has a number of drawbacks. First, commands provided by an programmer to a debugger, after a breakpoint is encountered, to enable the thread in which the breakpoint instruction was provided may never be completed because that thread may block waiting for a resource that is currently allocated to and owned by another thread. In addition, a program may make use of library threads for, for example, communication among processes, which may not be known to the programmer. If a library thread is stalled, the program being debugged may experience communication errors. Furthermore, such debuggers typically do not scale well as the number of threads increases.